There has been a tremendous increase in the number and type of applications (user-oriented specific-function software) provided via internet-related networks (e.g., the World Wide Web (“WWW”)) over the last decade. The application is created using an authoring language (e.g., HTML) that defines the structure and layout of the application UI. For example, HTML defines structure and layout using a variety of language element descriptors (e.g., tags and attributes). Typical web-based applications are presented using a client/server programming model. In such a model, an application provider provides the application on a server digital processing system (“DPS”), and an end-user of the application accesses the application via a client DPS. For example, for web-based applications, the server DPS houses a program that provides requested HTML to a client DPS when requested.
Typically a software vendor will create an application UI template. The HTML code that defines the structure and layout of the application UI template is contained in a generic layout file (“GLF”). The application UI template can be used to configure multiple different application UIs. The application provider obtains the application UI template from the software vendor and customizes the application UI configuration to meet their specific needs. However, the ability to easily modify the application UI template is often quite limited. That is, an application provider can configure the application UI, but modifications to the generic layout require editing the HTML code of the GLF. FIGS. 1A and 1B illustrate an application UI template and requirements for customization and modification in accordance with the prior art. Application UI template 100, shown in FIG. 1A, contains a number of placeholders 101–106. The GLF specifies the number and position of the placeholders, the size of the placeholder is not fixed, and can expand or shrink depending on the UI object placed in it. Using a tools editor, the application provider can then drag objects, such as fields and controls (e.g., fields, push buttons, scroll bars, etc.), and drop them within the placeholders 101–106. That is, the tools editor allows the application provider to move an object from one place to another on a display screen to configure the application UI. This is accomplished, for example, by selecting the object with a pointing device (e.g., a mouse) and directing it to a new location. For example, as shown in FIG. 1, field names, “Account Number,” “Date,” and “Contact” are placed in placeholders, 101, 103, and 105, respectively. Edit fields corresponding to each field name are placed in placeholders 102, 104, and 106, respectively. A placeholder may be configured to show both the field name and edit field. Internally, only one object is mapped to the placeholder. The particular objects placed within the placeholders constitute an applet, which is a logical user interface entity that displays information to the end user (e.g., a form Applet), which dictates how the application is presented. Information regarding each object (e.g., description of the object) contained in the applet and the corresponding placeholder for each object is kept in a database. Determining the applet (e.g., moving various objects within the existing placeholders) can be accomplished fairly easily using a tools editor. In this way an application provider customizes the application UI template according to the specific needs of the particular application provider. However, the tools editor cannot be used where the application provider desires a more substantial modification to the application UI template (e.g., modifying the generic layout structure). Modifications to the size and position of any of the placeholders, as well as adding or removing placeholders, require editing the HTML code of the GLF. For example, FIG. 1B illustrates a customization of the application UI template 100. In application UI template 110, shown in FIG. 1B, placeholders 102, 104, and 106 have been repositioned so that they are beneath the placeholders containing the corresponding field names. Also, the size of placeholder 102 has been increased (e.g., to accommodate a larger account number). Further, additional placeholders, 107 and 108 have been added to the application UI template to provide a “Comments” field name and corresponding edit field, respectively. In order to make these modifications, the application provider would have to access and edit the HTML of the GLF. The application provider would use a text editor to access the GLF and then make appropriate additions to the HTML, including creating a new HTML to effect the desired layout of the application UI. Depending upon the nature of the modifications desired, this process may require a substantial amount of time and effort. Moreover, editing the GLF requires a fairly high level of expertise and commensurate expense. The cost and effort involved in configuring the application UI beyond the confines of the application UI template is a substantial drawback to current application UI layout schemes.
Another related drawback is the difficulty encountered in migrating applets created in one authoring language to applets formed in another (e.g., migrating non-HTML applets to HTML applets). For example, when mapping controls from, for example, a coordinate-based layout to the placeholders of a typical application UI template, it may not be possible to determine an application UI template that has a placeholder layout that closely matches the coordinate-based layout. Application providers are forced to expend a great deal of time and effort to modify the migrated applets to match the number, size, and position of the original applets.